why does the netmask have to be the last 8 bits? What is wrong with being 16 bits instead?

In order to make it work correctly for netmask with more than 8 bits, it would be better to invert the byte order when IPAddress is cast to uint32_t.
I'm not sure that changing it would not break the code in other places or for other users.
Given that this issue has been already there since the very beginning, I just added code to prevent it from happening, limiting the netmask to 8 bits.

Example:
1.2.3.255 goes to 0xFF030201 in the current IPAddress Class casting method.
Adding 1, means to add (1 << 24) and it goes to 0x00030201 => IP 1.2.3.0 (it is worst when adding 11 << 24 to create a DHCP range).
If it were inverted, it would go to 0x010203FF, instead.
So adding 1 would result in 0x01020400 => IP 1.2.4.0, respectively, adding 11 would result in 0x01020410 => IP 1.2.4.10 (a lot better way to make the increment!)

It can be achieved by forcing this byte order inversion/reversion in the WiFiGenericClass code... is it worth it?

Inverting the bytes also makes it way easier to compare (uint32_t) IPAddress (greater, less than) in order to check if it belongs to an IP range or if it could break netmask limits and so on.

But inverting it will make it otherwise incompatible with everything else. We need to have the byte order that computers and IDF use. I do not see a reason why not add a method/methods to internally flip the order and do the operations agains another IP :)

OK, I'll add the code for it.

@me-no-dev - I tested it with netmask 255.255.0.0 for these cases:
1- AP = 192.168.1.250 and DHCP Range = 192.168.1.251 to 192.168.2.4
2- AP = 192.168.1.1 and DHCP Range = 192.168.2.1 to 192.168.2.10

In both cases the IDF call tcpip_adapter_dhcps_option() fails and returns error 0x5001.
It only works if AP IP address and DHCP range are in the same network with netmask 255.255.255.0 to 255.255.255.240
So, it seems that IDF only works with 8 bits subnet.

Therefore, this PR is ready.

Confirmed by looking into the esp_netif_lwip.c code:
https://github.com/espressif/esp-idf/blob/master/components/esp_netif/lwip/esp_netif_lwip.c#L1857-L1862

it only uses the last 8 bits of the AP address, limiting netmask effect to also 8 bits.

                    /*config ip information must be in the same segment as the local ip*/
                    softap_ip >>= 8;
                    if ((start_ip >> 8 != softap_ip)
                        || (end_ip >> 8 != softap_ip)) {
                        return ESP_ERR_ESP_NETIF_INVALID_PARAMS;
                    }

This PR is ready for merging.

I also found out an IDF limit for the size of DHCP range: DHCPS_MAX_LEASE, default is 0x64 = 100 addresses (lwip/include/apps/dhcpserver/dhcpserver.h)

Commited changes that prepare the code for any netmask (for the future, when IDF supports it as well).

This PR is ready for merging.